\documentclass[12pt,a4paper,english]{book}
\usepackage{url}
\usepackage{color}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{fancyhdr}
\usepackage{listings}
\usepackage[autocite=inline, labelalpha=true, style=alphabetic]{biblatex}
\usepackage{makeidx}
\usepackage{tocbibind}
\usepackage[lmargin=2.5cm, rmargin=2.5cm,tmargin=2.5cm,bmargin=2.5cm]{geometry}
\usepackage[compact]{titlesec}

\nocite{*}

\titleformat{\chapter}[display]
  {\bfseries\Huge}
  {\filright\Large\chaptertitlename\ \thechapter}
  {0mm}{\filright}
\titlespacing*{\chapter}
  {0pt}{-10pt}{15pt}

\makeindex

\bibliography{mybib}


\newcommand{\keyword}[1]{\index{#1}#1}
\newcommand{\ocite}[1]{\footfullcite{#1}}
\newcommand{\oscite}[1]{\cite{#1}}
\newcommand{\paraph}{\paragraph{}}

\let\cleardoublepage\clearpage

\pagestyle{fancy}
\fancyhead{}
\fancyfoot{}
\fancyfoot[C]{\thepage}
\fancyhead[LE,RO]{\slshape \rightmark}
\fancyhead[LO,RE]{\slshape \leftmark}

\renewcommand{\headrulewidth}{0pt}
\renewcommand{\footrulewidth}{0pt}

\definecolor{darkgray}{rgb}{0.47,0.79,0.47}

\hypersetup{
  colorlinks = true,
  linkcolor=blue,   % color of internal links
  citecolor=blue,   % color of links to bibliography
  urlcolor=blue,    % color of external links
  pagebackref=true,
  implicit=false,
  bookmarks=true,
  bookmarksopen=true,
  pdfdisplaydoctitle=true
}



\begin{document}

\lstset{ %
language=Octave,                % choose the language of the code
basicstyle=\footnotesize,      % the size of the fonts that are used for the code
numbers=left,                   % where to put the line-numbers
numberstyle=\footnotesize,      % the size of the fonts that are used for the line-numbers
stepnumber=0,                   % the step between two line-numbers. If it's 1 each line
                                % will be numbered
numbersep=5pt,                  % how far the line-numbers are from the code
backgroundcolor=\color{white},  % choose the background color. You must add \usepackage{color}
showspaces=false,               % show spaces adding particular underscores
showstringspaces=false,         % underline spaces within strings
showtabs=false,                 % show tabs within strings adding particular underscores
frame=tb,
tabsize=2,	                % sets default tabsize to 2 spaces
captionpos=b,                   % sets the caption-position to bottom
breaklines=true,                % sets automatic line breaking
breakatwhitespace=false,        % sets if automatic breaks should only happen at whitespace
title=\lstname,                 % show the filename of files included with \lstinputlisting;
                                % also try caption instead of title
escapeinside={\%*}{*)},         % if you want to add a comment within your code
morekeywords={*,...},            % if you want to add more keywords to the set
keywordstyle={\color{blue}},
commentstyle={\color{darkgray}},
stringstyle={\color{red}},
framexleftmargin=3pt,
framexrightmargin=3pt,
framextopmargin=3pt,
framexbottommargin=3pt
}

\title{The oark book: \url{http://code.google.com/p/oark/}\newline\begin{figure} [h]
\begin {center}
\includegraphics[width=0.2\textwidth]{oark.jpg}
\end {center}
\end{figure} \newline The Open Source Anti Rootkit}
\author{David Reguera Garcia aka Dreg - Dreg@fr33project.org \\\\Co-authors: -}
\maketitle
\date{}

\titlespacing*{\chapter}{0pt}{-40pt}{15pt}
\fancyhead[LE,RO]{}
\setcounter{tocdepth}{3}
\tableofcontents
\fancyhead[LE,RO]{\slshape \rightmark}

\chapter{Call Gates and GDT/LDT}

\section{GDT/LDT}
\paraph{}
The Global Descriptor Table or \keyword{GDT} (extracted from Wikipedia\ocite{wikglb2010}) is a data structure used by Intel x86-family processors in order to define the characteristics of the various memory areas used during program execution, for example the base address, the size and access privileges like executability and writability. These memory areas are called segments in Intel terminology. \ocite{Int6432sofdvman3A}

\paraph{}
The GDT can hold things other than segment descriptors as well. Every 8-byte entry in the GDT is a descriptor, but these can be Task State Segment (or TSS) descriptors, Local Descriptor Table (LDT) descriptors, or Call Gate descriptors. The last one, Call Gates, are particularly important for transferring control between x86 privilege levels although this mechanism is not used on most modern operating systems.

\paraph{}
There is also an LDT or Local Descriptor Table. The LDT is supposed to contain memory segments which are private to a specific program, while the GDT is supposed to contain global segments. The x86 processors contain facilities for automatically switching the current LDT on specific machine events, but no facilities for automatically switching the GDT.

\paraph{}
Every memory access which a program can perform always goes through a segment. On the 386 processor and later, because of 32-bit segment offsets and limits, it is possible to make segments cover the entire addressable memory, which makes segment-relative addressing transparent to the user.

\paraph{}
In order to reference a segment, a program must use its index inside the GDT or the LDT. Such an index is called a segment selector or selector in short. The selector must generally be loaded into a segment register to be used. Apart from the machine instructions which allow one to set/get the position of the GDT (and of the Interrupt Descriptor Table) in memory, every machine instruction referencing memory has an implicit Segment Register, occasionally two. Most of the time this Segment Register can be overridden by adding a Segment Prefix before the instruction.

\paraph{}
Loading a selector into a segment register automatically reads the GDT or the LDT and stores the properties of the segment inside the processor itself. Subsequent modifications to the GDT or LDT will not be effective unless the segment register is reloaded.

\section{Call Gates}

\paraph{}
A Call Gate \oscite{Int6432sofdvman3A} is a mechanism in the Intel x86 architecture to change privilege levels of the CPU when running a predefined function that is called by the instruction CALL/JMP FAR.

\paraph{}
A call to a Call Gate allows you to obtain higher privileges than the current, for example we can execute a routine in ring0 using a CALL FAR in ring3. A Call Gate is an entry in the GDT (Global Descriptor Table) or LDT (Local Descriptor Table). There are a GDT for each CORE, and each GDT can have one or more LDTs \ocite{dregrkar2010}.

\paraph{}
Windows doesn't use Call Gate for anything special, but there are malware, as the worm Gurong.A \ocite{w32guronga2006} , that installs a Call Gate via DevicePhysicalMemory to execute code on ring0. An article that talks about it is "Playing with Windows/dev/(k)mem" \ocite{crazylplayph2002}.

\paraph{}
Nowadays we can't easily access to /Device/PhysicalMemory, I recommend reading the presentation by Alex Ionescu at RECON 2006 "Subverting Windows 2003 SP1 Kernel Integrity Protection" \ocite{alexionsubwin2006}. Also, there are examples \ocite{saccocallg2006} in the wired that use the API ZwSystemDebugControl \ocite{undocntinternals} to install a Call Gate, but Ionescu's article says that it doesn't work nowadays (although there are techniques to reactivate them).

\paraph{}
Gynvael and j00ru made a Call-Gate mechanism in kernel/driver exploit development on Windows \ocite{j00rugyngdtldt2010}, or, to be more precise, to use a write-what-where condition to convert a custom LDT entry into a Call-Gate (this can be done by modifying just one byte), and using the Call-Gate to elevate the code privilege from user-land to ring0.

\paraph{}
David Reguera Garcia aka Dreg made a Call Gate detector for the free anti-rootkit Rootkit Unhooker \ocite{diableprkusr12010}. The next releases have new features to detect other new stuff like the 'new LDT Forward to user mode attack' (published also in the Gynvael and j00ru's paper). With this attack, an attacker can add a Call Gate or other descriptor to LDT without restrictions from user mode.

\paraph{}
An entry in the GDT/LDT looks like this:
\lstset{language=C,caption=GDT/LDT Descriptor structure}
\begin{lstlisting}
typedef struct _SEG_DESCRIPTOR
{
    WORD size_00_15;
    WORD baseAddress_00_15;
    WORD baseAddress_16_23:8;
    WORD type:4;
    WORD sFlag:1;
    WORD dpl:2;
    WORD pFlag:1;
    WORD size_16_19:4;
    WORD notUsed:1;
    WORD lFlag:1;
    WORD DB:1;
    WORD gFlag:1;
    WORD baseAddress_24_31:8;
} SEG_DESCRIPTOR, *PSEG_DESCRIPTOR;
\end{lstlisting}

\paraph{}
A Call Gate is an entry type in the GDT/LDT which has the following appearance:
\lstset{language=C,caption=Call Gate Descriptor structure}
\begin{lstlisting}
typedef struct _CALL_GATE_DESCRIPTOR
{
    WORD offset_00_15;
    WORD selector;
    WORD argCount:5;
    WORD zeroes:3;
    WORD type:4;
    WORD sFlag:1;
    WORD dpl:2;
    WORD pFlag:1;
    WORD offset_16_31;
} CALL_GATE_DESCRIPTOR, *PCALL_GATE_DESCRIPTOR;
\end{lstlisting}

\begin{itemize}
\item {{\bf offset\_00\_15:} is the bottom of the address of the routine to be executed in ring0, {\bf offset\_16\_31} is the top.}
\item {{\bf selector:} specifies the code segment with the value KGDT\_R0\_CODE (0x8), the routine will run ring0 privileges.}
\item {{\bf argCount:} the number of arguments of the routine in DWORDs.}
\item {{\bf type:} the descriptor type for a 32-bit Call Gate needs the value 0xC}
\item {{\bf dpl:} minimum privileges that the code must have to call the routine, in this case 0x3, because it will be called by the routine ring3}
\end{itemize}

\paraph{}
To create a Call Gate we can follow the following steps:
\begin{enumerate}
\item {Build the Call Gate that points to our routine.}
\item {Set the code only in a core (remember: there are a GDT for each CORE.)}
\item {Read the GDTR register in order to find the GDT address and the size using SGDT instruction:

\lstset{language=C,caption=GDTR register}
\begin{lstlisting}
typedef struct _GDTR
{
    WORD nBytes;
    DWORD baseAddress;
} GDTR;
\end{lstlisting}

We can obtain the number of entries (number of GDT descriptors) with GDTR.nBytes/8.
}
\item {Find a free entry in the GDT/LDT.}
\item {Write the Call Gate descriptor.}
\item { To call the Call Gate is only necessary to make a CALL/JMP FAR to the GDT/LDT selector:
\begin{itemize}
\item { ie if we've introduced the Call Gate at the entry {\bf 100} of the {\bf GDT}, the user space application must execute a CALL/JMP FAR {\bf 0x320}:00000000. 0x320 is in binary 1100100 {\bf 0} 00, then the entry is:1100100 (100 in binary is 1100100), {\bf TI=0} (entry is in {\bf GDT}) RPL=00.. The other part of the FAR CALL is not useful but must be in the instruction.}
\item { ie if we've introduced the Call Gate at the entry {\bf 100} of the {\bf LDT}, the user space application must execute a CALL/JMP FAR {\bf 0x324}:00000000. 0x324 is in binary 1100100 {\bf 1} 00, then the entry is:1100100 (100 in binary is 1100100), {\bf TI=1} (entry is in {\bf LDT}) RPL=00..}
\end{itemize}
}

\end{enumerate}

\subsection{Windows specific}
\paraph{}
Now is time for a more detailed view. On Windows is easy to control in which core do you want run the code, it is only necessary two APIs, to get the number of COREs you can use GetSystemInfo:

\lstset{language=C,caption=API to get the system info}
\begin{lstlisting}
void WINAPI GetSystemInfo( LPSYSTEM_INFO lpSystemInfo );
\end{lstlisting}

\paraph{}
SYSTEM\_INFO has the following appearance:

\lstset{language=C,caption=SYSTEM INFO structure}
\begin{lstlisting}
typedef struct _SYSTEM_INFO {
    // .............
    DWORD dwNumberOfProcessors;
    // .............
}SYSTEM_INFO;
\end{lstlisting}

\paraph{}
We do a loop with the field dwNumberOfProcessors that executes CORE by CORE by adding the Call Gate or you can also force the Call Gate only to the first core (1) and the user space application will be executed only in the core 1, this is accomplished using the API: SetThreadAffinityMask, as follows:

\lstset{language=C,caption=SetThreadAffinityMask API}
\begin{lstlisting}
DWORD_PTR WINAPI SetThreadAffinityMask( HANDLE hThread, DWORD_PTR dwThreadAffinityMask );
\end{lstlisting}

\paraph{}
Passing a GetCurrentThread() and the value 1 as AffinityMask, Be careful, DWORD\_PTR is not a pointer to a DWORD, is passed by value:

\lstset{language=C,caption=SetThreadAffinityMask to core 1}
\begin{lstlisting}
Affinity = 1;
SetThreadAffinityMask( GetCurrentThread(), Affinity );
\end{lstlisting}

\paraph{}
You can do a loop for the number of processors and the rate variable (the first core is 1 not 0) using Affinity you can install a Call Gate in all the cores. Take notice that it's a mask, so you should use a bit shift like: AffinityMask = 1 << index\_variable to scroll through the cores.

\paraph{}
To install a Call Gate from a driver your need other APIs, to obtain the number of cores:

\lstset{language=C,caption=Get the number of cores from a driver}
\begin{lstlisting}
ZwQuerySystemInformation( SystemBasicInformation, & system_basic_information, sizeof( system_basic_information ), NULL );
\end{lstlisting}

\paraph{}
To change the core, -2 is the equivalent to GetCurrentThread():

\lstset{language=C,caption=Change the affinity from a driver}
\begin{lstlisting}
ZwSetInformationThread( (HANDLE) -2, ThreadAffinityMask, & AffinityMask, sizeof( AffinityMask ) );
\end{lstlisting}

\paraph{}
With this information you can install/detect call gates in the GDTs and LDTs of all cores. But for the best detection it is necessary view all LDTs, and the Windows Scheduler uses the same entry in the GDT for all processes, and only with the last information you can loss some LDTs.

\subsubsection{LDT specific}
\paraph{}
Windows Scheduler uses the same entry in the GDT for LDT in all processes and it is necessary read the LDTs of all processes, there are two ways: Using the Windows API and DKOM (Direct Kernel Object Manipulation).

\chapter{PEB Hooking}
\paraph{}
PEB HOOKING method consists in supplanting a DLL in memory using a fake DLL, so all modules of a process now will use the fake DLL. Deroko writes in ARTeam 2 "PEB DLL Hooking Novel method to Hook DLLs"\ocite{deropebdllh2006} the first public article about PEB Hooking (including a POC). After, Juan Carlos Montes and David Reguera Garcia writes an article for Phrack 65 called: phook - The PEB Hooker\ocite{dregshearphk2008}, this article have more information and other tools.

\paraph{}
After David Reguera Garcia writes other article \ocite{dreggendllpeb2009} and a new engine called dwtf\ocite{dregdwtf2010} to generate Fake DLLs at runtime, in the past you needed a fake DLL repository for the different DLLs versions, a useful engine for the system DLLs (Windows SP1 have different system DLLs than Windows SP2 etc). Also David Reguera Garcia aka Dreg made a PEB Hooking detector for the free anti-rootkit Rootkit Unhooker \ocite{diablorku3895sr22010}.

\paraph{}
Process Environment Block (PEB) is a structure located in the user's space, that contains the process' enviroment data: Enviroment variables. Loaded modules list...

\lstset{language=C,caption=Process Environment Block}
\begin{lstlisting}
typedef struct _PEB
{
    //...
    PVOID ImageBaseAddress;
    PPEB_LDR_DATA LoaderData;
    //...
} PEB;
\end{lstlisting}

\paraph{}
For PEB HOOKING we need use the LoaderData field, this field is a structure in which there are some data about the modules of a process. It is a doubly linked list and it can be sorted by Order of: loading, in memory and initialization. All flink and blink fields in LIST\_ENTRY are in reality pointers to LDR\_MODULE. We are going to manipulate from LDR\_MODULE: BaseAddress, EntryPoint and SizeOfImage.

\paraph{}
It is necessary to search DLL\_FAKE and DLL\_REAL for some identificative fields of LDR\_MODULE, once found the following data will be exchanged: EntryPoint, BaseAddress and SizeOfImage.

\lstset{language=C,caption=PEB Loader Data}
\begin{lstlisting}
typedef struct _PEB_LDR_DATA
{
    ...
    //BOOLEAN Initialized;
    PVOID SsHandle;
    LIST_ENTRY InLoadOrderModuleList;
    //....
}
\end{lstlisting}

\lstset{language=C,caption=Loader Module Data}
\begin{lstlisting}
typedef struct _LDR_MODULE
{
    LIST_ENTRY InLoadOrderModuleList;
    // ...
    PVOID BaseAddress;
    PVOID EntryPoint;
    ULONG SizeOfImage;
    // ...
} LDR_MODULE, *PLDR_MODULE;
\end{lstlisting}

\section{Detection}
\paraph{}
The PEB Hooking detection is in experimental stage yet. The current strategy is check some incongruities, and detects a bad PEB Hooking stealth. Of course some methods have more false positives than others (Depends on the environment and other factors). Of course, detects HIDDEN DLLs also is a good idea, for example a PEB HOOKING can have a good design, but if it try to hide a DLL with a bad design you can detect a suspicious enviroment etc.

\paraph{} The information in PEB useful to check if there are PEB HOOKING or not are:
\lstset{language=C,caption=Loader Module Data useful for the detection}
\begin{lstlisting}
typedef struct _LDR_MODULE
{
    // ...
    PVOID BaseAddress;
    PVOID EntryPoint;
    ULONG SizeOfImage;
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    // ...
    ULONG TimeDateStamp;

} LDR_MODULE, *PLDR_MODULE;
\end{lstlisting}

{\bf FullDllName} is the FULL PATH in disk of the DLL, and the {\bf BaseDllName} the name of the DLL.

\paraph{}
The LDR\_MODULE information can be compared with the DISK file information and also can be compared with the VAD (Virtual Address Descriptor) information. Virtual Address Descriptor tree is a kernel data structure found in Windows memory, can provide such an abstraction layer over the page directory and page tables by describing the memory ranges allocated by a process as they might be seen by the process as mapped files, loaded DLLs, or privately allocated regions... \ocite{brendogavad2007}

\lstset{language=C,caption=MMVAD data useful for the detection}
\begin{lstlisting}
typedef struct _MMVAD
{
    // ...
    UINT32 StartingVpn;
    UINT32 EndingVpn;
    // ...
} MMVAD, *PMMVAD;
\end{lstlisting}

\paraph{}
With the StartingVpn you have the base address of the DLL (the same info of BaseAddress of LDR\_MODULE) and the (EndingVpn + 1) - StartingVpn is the size of image (the same info of SizeOfImage of LDR\_MODULE).

The MMVAD struct is different in some Windows versions, for example XP have a "struct CONTROL\_AREA* ControlArea" and the next Windows versions have a struct SUBSECTION* Subsection, which have a "struct CONTROL\_AREA":

\lstset{language=C,caption=MMVAD data after XP have a pointer to SubSection}
\begin{lstlisting}
typedef struct _MMVAD_AFTER_XP
{
    // ...
    struct _SUBSECTION* Subsection;
    // ...
} MMVAD_AFTER_XP, *PMMVAD_AFTER_XP;
\end{lstlisting}


\lstset{language=C,caption=SUBSECTION structure}
\begin{lstlisting}
typedef struct _SUBSECTION
{
    struct _CONTROL_AREA* ControlArea;
    // ...
} SUBSECTION, *PSUBSECTION;
\end{lstlisting}

\lstset{language=C,caption=MMVAD data in XP have a pointer to ControlArea}
\begin{lstlisting}
typedef struct _MMVAD_XP
{
    // ...
    struct _CONTROL_AREA* ControlArea;
    // ...
} MMVAD_XP, *PMMVAD_XP;
\end{lstlisting}

\lstset{language=C,caption=ControlArea struct}
\begin{lstlisting}
typedef struct _CONTROL_AREA
{
    // ...
    PVOID FilePointer; // struct _FILE_OBJECT * in XP and after a EX\_FAST\_REF to struct _FILE_OBJECT *
} CONTROL_AREA,*PCONTROL_AREA;
\end{lstlisting}

The FilePointer in Windows XP is a normal pointer, and after XP is a EX\_FAST\_REF:

\lstset{language=C,caption=EX\_FAST\_REF struct}
\begin{lstlisting}
typedef struct _EX_FAST_REF
{
    union
    {
        PVOID Object;
        ULONG_PTR RefCnt:3;
        ULONG_PTR Value;
    };
} EX_FAST_REF, *PEX_FAST_REF;
\end{lstlisting}

To convert a EX\_FAST\_REF to a normal pointer you need clean the RefCnt of the pointer: for example with two shifts:

\lstset{language=C,caption=cleaning RefCnt of a EX\_FAST\_REF pointer}
\begin{lstlisting}
fast_ref_ptr.Value >>= 3;
fast_ref_ptr.Value <<= 3;
\end{lstlisting}

\paraph{}
Then the FilePointer is the type of FILE\_OBJECT, this struct have the File Name information:

\lstset{language=C,caption=FILE\_OBJECT}
\begin{lstlisting}
typedef struct _FILE_OBJECT
{
    //...
    struct _UNICODE_STRING FileName;
} FILE_OBJECT, *PFILE_OBJECT;
\end{lstlisting}

The UNICODE STRING FileName have the FULL PATH of the DLL, from this field you can extract the FULL PATH of the DLL to compare with the FullDllName of LDR\_MODULE, and from the FULL PATH you can extract the DLL name to compare with the BaseDllName of LDR\_MODULE.

\paraph{}
if the DLL file do not exist in the disk maybe this is a suspicious enviroment, to compare the memory information with the file information of the DLL is necessary read the PE format \ocite{microsoftpecoff2010}:

The first header of the file is the DOS HEADER, it have the offset to the PE header:
\lstset{language=C,caption=IMAGE\_DOS\_HEADER structure}
\begin{lstlisting}
typedef struct _IMAGE_DOS_HEADER
{
    //...
    LONG e_lfanew;
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
\end{lstlisting}

The IMAGE NT HEADERS is the PE HEADER, the interesting fields is the FileHeader and the OptionalHeader:
\lstset{language=C,caption=IMAGE\_NT\_HEADERS structure}
\begin{lstlisting}
typedef struct _IMAGE_NT_HEADERS
{
    //...
    IMAGE_FILE_HEADER     FileHeader;
    IMAGE_OPTIONAL_HEADER OptionalHeader;
} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;
\end{lstlisting}

The FileHeader have the TimeDateStamp value which is the same of the LDR\_MODULE TimeDateStamp:
\lstset{language=C,caption=IMAGE\_FILE\_HEADER structure}
\begin{lstlisting}
typedef struct _IMAGE_FILE_HEADER
{
    //...
    DWORD TimeDateStamp;
    //...
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
\end{lstlisting}

And the Optional Header have the others LDR\_MODULE data: SizeOfImage is the SizeOfImage of the LDR, ImageBase is the BaseAddress of the LDR, and AddressOfEntryPoint is the EntryPoint - BaseAddress of the LDR:
\lstset{language=C,caption=IMAGE\_OPTIONAL\_HEADER structure}
\begin{lstlisting}
typedef struct _IMAGE_OPTIONAL_HEADER
{
    // ...
    DWORD AddressOfEntryPoint;
    // ...
    DWORD ImageBase;
    // ...
    DWORD SizeOfImage;
    // ...
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;
\end{lstlisting}

\paraph{}
With this information the current methods to detect PEB HOOKING are, it includes the false positives information:

\begin{itemize}
\item { Checks if the VAD (Virtual Address Descriptor) info is different of PEB INFO:
\begin{itemize}
\item { {\bf VAD FULL PATH name:} without problems }
\item { {\bf VAD DLL name:} without problems }
\item { {\bf VAD DLL size:} without problems }
\end{itemize}
}
\item { {\bf Same DLL Name in two or more PEB entries:} without problems }
\item { {\bf Same DLL FULL Name PATH in two or more PEB entries:} false positives in some enviroment }
\item { Different memory data and PE32 raw file data:
\begin{itemize}
\item { {\bf SIZE OF IMAGE in PEB:} false positives with some packers etc. }
\item { {\bf ENTRY POINT in PEB:} false positives, some DLLs have not got entry point etc. }
\item { {\bf TIME DATE STAMP in PEB:} without problems. }
\end{itemize}
}
\item { {\bf Different DLL Name of the FULL PATH NAME (string inside):} without problems }
\end{itemize}

\paraph{}
By default to check all DLLs of all process in memory have a very poor performance because the DISK I/O for all DLLs, then the DISK FILE methods for the quick scan must be disabled. The useful and trusted information for a quick scan is:

{\bf
\begin{itemize}
\item { All VAD stuff }
\item { Same DLL Name in two or more PEB entries }
\item { Different DLL Name of the FULL PATH NAME (string inside) }
\end{itemize}
}
And for the deep scan DISK FILE checks the useful and trusted information:

{\bf
\begin{itemize}
\item { check TIME DATE STAMP }
\end{itemize}
}

\paraph{}

\chapter{Greetings}
\paraph{}
0vercl0k aka Souchet Axel, George Nicolaou, DiabloNova aka EP\_X0FF, Ivanlef0u, Gynvael, j00ru

\fancyhead[LE,RO]{}
\printbibliography[heading=bibintoc]

\clearpage
\phantomsection
\printindex


\end{document}

























